Software Configuration Management as a Mechanism for Multidimensional Separation of Concerns

Real software rarely conforms to one single view of the program structure; instead, software is sufficiently complex that the structure of the program is best understood as a collection of orthogonal divisions of the program into components. However, most software tools only recognize the decomposition of the program into source files, forcing the programmer to adopt one primary program decomposition which is well-suited to some tasks and poorly suited to others. Software tools can overcome this weakness by allowing programmers to transform their view of the program to a structure which is more appropriate for the task they need to perform. We propose that a software configuration management (SCM) system, which stores the source code for the project, can perform this task. By providing the SCM system with the capability to generate orthogonal program organizations through compositions of program fragments, the SCM system can support orthogonal decompositions of the program without performing any automatic alteration of the source code. To illustrate the importance of using different decompositions, consider the compiler, a classic example of a project with multiple orthogonal decompositions. The compiler’s two more obvious decompositions—one structural, one functional—are illustrated architecturally in figure 2 A. The structural decomposition is the interpreter design pattern, in which the system is decomposed into components (classes), where each component defines all the behaviors of one structural unit of the program. This decomposition is based on an inheritance hierarchy, which is in turn based on the syntactic structure of the language. A functional view sees the compiler as a chain of components connected by data flowing between the components. The functional decomposition is based on this view: the parser generates an abstract syntax tree (AST) from the source code. The analyzer performs a pass over the AST, decorating nodes with semantic information. The intermediate code generator creates a stream of intermediate code instructions during its pass over the decorated AST. The optimizer operates on the intermediate code stream and generates a new optimized stream. Finally, the code generator translates the optimized intermediate code into executable binary code. In the functional decomposition, each of these components is provided by a component of the system. Given conventional tools, these two decompositions are mutually exclusive. The code can be written in the interpreter pattern, but then the functional decomposition is not available. When faced with a programming task well-suited to the functional decomposition (for instance, replacing the type analyzer with a better type inference algorithm), the programmer needs to view and manipulate code scattered through dozens of different files. The overall operation of the functional components is obscured, and changes to a program’s functionality become significantly more difficult. Adopting the functional decomposition rather than the structural decomposition makes replacing functional components easier but produces its own set of problems. For instance, in the functional decomposition, adding a new syntactic structure to the language requires changing all of the components of each functional decomposition, whereas it only requires adding a single new component to the structural decomposition. The solution to this problem is to build new tools that